[JAWS ミート 2024] 『踏み台の運用が変わる？ VPC 上で起動できるようになった CloudShell を語る』というタイトルで登壇しました。#jawsmt #jawsug

平木佳介

2024.07.06

こんにちは、AWS 事業本部の平木です！

本日、愛知県豊橋市の BASE CAMP KITI にて開催された JAWS-UG 東海道主催の JAWS ミート 2024 にて、「踏み台の運用が変わる？ VPC 上で起動できるようになった CloudShell を語る」というタイトルで登壇したため登壇資料を公開します。

登壇資料

登壇内容

イントロダクション

皆さんは踏み台サーバを運用していますか？

踏み台サーバを運用しようと思うといくつか悩みの種が出てきます。

少し RDS へ接続したいだけの踏み台サーバなのに EC2 を停止しても EBS の料金が発生してしまう
踏み台サーバの分、脆弱性対策の対象が増えてしまう
EC2 を構築する際に申請が必要な場合、わざわざ申請が面倒

など微妙に面倒に感じることないでしょうか。

keisuke-devio-2024-07-05-19-19-12

そんな悩みを解決するかもしれないアップデートを今回ご紹介します。

keisuke-devio-2024-07-05-19-21-16

※当該ブログは以下となります。

今までの踏み台

まず、今まで踏み台サーバを運用するときどんなだったかを思い出します。

初めに、プライベートサブネットの EC2 に接続する場合を考えると、
踏み台サーバを使用せずとも、Systems Manager のセッションマネージャーや EC2 Instance Connect endopoint を活用することで踏み台サーバの代替手段として採用できました。

keisuke-devio-2024-07-05-19-26-45

それぞれの詳細と違いについては下記ブログを参照ください。

しかし、RDS や Redshift といったマネージドな DB に接続する場合を考えると、
結局踏み台サーバが必要でした。

keisuke-devio-2024-07-05-19-27-53

そこで今回登場した CloudShell VPC environment を活用すると下記のように接続できます。

keisuke-devio-2024-07-05-19-28-53

そんな CloudShell VPC environment について解説します。

CloudShell VPC environment について

CloudShell VPC environment は先月 6 月 13 日に追加された機能で文字通り、VPC 環境をサポートする機能となります。

keisuke-devio-2024-07-05-19-31-44

こちらの機能は、

まずその名の通り、VPC 環境をサポートした機能です。
パブリック環境として提供されていた CloudShell がプライベートに使用することができるようになりました。

またアクセス制御はセキュリティグループで行います。
CloudShell VPC environment を構築時に ENI が払い出されその ENI にセキュリティグループが関連付けられます。

その他、CloudShell はマネージドサービスであるためパッチ適用などのセキュリティ面を AWS が行ってくれます。

keisuke-devio-2024-07-06-08-49-15

構成イメージとしては以下です。

CloudShell とクライアントとの間は IAM 認証となるためポリシーに沿ってアクセス制御が可能です。

CloudShell と各 AWS リソースとの間はセキュリティグループによってアクセス制御が可能となります。

またインターネットへ出たい場合には、インターネットゲートウェイへのルーティングが存在すればインターネットへ出ることも可能です。

keisuke-devio-2024-07-06-08-53-53

CloudShell を踏み台として活用することで、

EC2 のインスタンス使用料を払う必要がなく
パッチ適用の考慮も不要で
サーバの構築も不要

などハッピーなことが盛りだくさんです。

keisuke-devio-2024-07-06-08-56-51

ただ考慮すべき事項がいくつかあるため解説します。

考慮すべきこと

開発者や担当者は EC2 を立てずに踏み台を作成できるのでハッピーかもしれませんが、
管理者から見ると気軽にプライベート空間内に本番環境などに接続できる可能性のあるリソースを作成されると困ると考える組織も当然あると思います。

その場合はある程度制限をかけないといけないシチュエーションも当然出てきます。

keisuke-devio-2024-07-06-09-28-17

それを見込んでか VPC 環境をサポートしたのと合わせて以下の IAM 条件キーが追加されました。

CloudShell:VpcIds
- 1 つ以上の VPC を許可/拒否する
CloudShell:SubnetIds
- 1 つ以上のサブネットを許可/拒否する
CloudShell:SecurityGroupIds
- 1 つ以上のセキュリティグループを許可/拒否する

keisuke-devio-2024-07-06-09-31-31

例えば下記のような使用例があります。

CloudShell:VpcIdsとNullを活用することで VPCIds のキーが存在する場合に CreateEnvironment アクションを制限可能です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudShellVpcEnvironments",
      "Action": [
        "cloudshell:CreateEnvironment"
      ],
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "Null": {
          "cloudshell:VpcIds": "false"
}}}]}

下記ブログにて他のパターンもご紹介しているためご参考にしていただければと思います。

その他にも、

「アクション」メニューからのデータのアップロード・ダウンロードは不可
- インターネットへ出れる環境であれば別のツールで実現可能
永続的なストレージは使用不可
- セッション終了時にホームディレクトリが削除されるため S3 へ保存などの仕組みが必要
ログイン履歴といった監査ログの機能は現在のところなし
- CloudTrail では StartSession,StartEnvironment というレコードが記録されるが VPC 環境かどうかの判別不能

などの制約事項があるため考慮する必要があります。